home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1199 / 1685 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.8 KB
  1. From: Stephan Haslbeck <haslbecs@informatik.tu-muenchen.de>
  2. Subject: Re: some more 110h4 clues...
  3. Date:     Wed, 6 Jul 1994 14:56:20 +0200
  4. In-Reply-To: <9407051353.AA00211@star.techfak.uni-bielefeld.de> from "itschere@TechFak.Uni-Bielefeld.DE" at Jul 5, 94 04:53:02 pm
  5. Mime-Version: 1.0
  6. Message-Id: <94Jul6.135628mesz.209273@hphalle0.informatik.tu-muenchen.de>
  7.  
  8. Torsten Scherer wrote:
  9.  
  10. >  How many getties do you run? If I start only one, evertything is fine
  11. > for me too.
  12.  
  13. When I start gem.sys, I don't start any getty at all. And starting
  14. init - getty - login - shell (without GEM) works alright.
  15. BTW, starting MultiGEM from a shell is very instable... 
  16. A few patches before the system hung after four or five key presses;
  17. now (I think it was the fselect-patch or something like that)
  18. it hangs only on key presses in the Gemini-1.99-console.
  19. Only starting GEM directly from mint.cnf works fine. Maybe this has something
  20. to do with my rather old version of gem.sys?  (I don't know the
  21. version number, but it has 273903 Bytes - what version is this?).
  22.  
  23. I just remember something strange:
  24. I think when I tried to start gem.sys with the latest patches 
  25. (I compile MiNT without GEM because my memory is very low with all
  26. that helper programs - NVDI, Speedo, Gemini, ScreenBlaster, etc. -
  27. no place for gcc 2.5.8 (!)), I didn't deactivate sockdev.xdd and
  28. nfs.xfs. It worked _with_ memory proctection. But then, I deactivated
  29. these two, and GEM only started _without_ memory protection. Can it be
  30. that the problem only arises on the _first_ call of Pexec and does not
  31. arise any more after sockdev and nfs started their daemons?
  32.  
  33. >  One possible explanation would be that p_vfork() attaches the parent's
  34. > basepage to the child and doesn't really copy it to something private and
  35. > leave the original attached to where it was. This way a subsequent p_exec()
  36. > would still have access to the basepage, but *not* if the parent has p_vforked
  37. > again in the meantime, attaching the basepage to the second child. Hmmm, I'm
  38. > quite uncertain about this, but maybe it can give another clue...
  39.  
  40. My problem can't have anything to do with do_vfork(), because MiNT
  41. itself uses Pexec(), and Pexec() does not use do_vfork(), does it?
  42. As I already said it's only the first Pexec()-call that causes
  43. the memory violation.
  44. I think you have more or less patches than me - we're just talking
  45. about different versions of MiNT (quite obvious with all those patch
  46. collections, though :-|).
  47.  
  48. Ciao,
  49. Stephan 
  50.  
  51. -- 
  52. +------------------------------+-----------------------------+
  53. |      Stephan Haslbeck           |    Fachschaft Informatik    |
  54. |       Agricolastr. 61           |   Technische Universitaet   |
  55. |      D-80686 Muenchen           |      Muenchen, Bayern         |
  56. +------------------------------+-----------------------------+
  57. |Motto: Es gibt keine Probleme,|
  58. |        nur Loesungen.           |
  59. +------------------------------+
  60.